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Description 

Field of the invention 

This invention relates to a transaction aulhoti2ation 
and alerting system, and mots particularly to a method 
and apparatus iof using a communications system to 
afen an interested party ot a recently coropieted trans-- 
action and/or to obtain authoriz&aon irons trie interested 
party for a pending transaction. 

Background of she Invention 

The credtf card Identification numbers assigned to 
credit card customers are presented to many different 
people m a variety of circumstances - when applying 
for financial sen/sees, when concluding purchases in a 
store, and when making purchases over the telephone, 
through the mail, or over e-mail (electronic mail). The 
large number of people ifiat have access foacustomer's 
credit card number has frequently led to traud. The ad- 
vantages of using credit cards, however, are substan- 
tial. The customer tinds their esc advantageous in thai 
he or she need no! carry cash or writs checks. Credit 
card purchases atso have advantages to the retailer as 
compared, tor example, to payment by check, since the 
credit card service provider ensures timely payment to 
the retailer, regardless of when the customer pays ins 
balance on the credit card account. However, credit 
cards or credit card numbers are often stolen, and credit 
card numbers are often used over the telephone or 
through the am Without any secure mechanism for con- 
firming the customer's identity 

Telephone calling card numbers have security prob- 
lems similar to those ot credit cards. These numbers are 
often spoken aloud or entered through a touch tone key- 
pad, thereby allowing others the opportunity to record 

to then fraudulently use the numbers. Another common 
source of fraud sterns from authorized usage of a credit 
card or a telephone calling card followed by a customer 
denial thai he or she made the purchase or placed the 
call Thus, Simply controlling access to the credit or call- 
ing card number without more may be inadequate. Com- 
puter access to secure databases is yet another exam- 
pie of a transaction that depends upon private customer 
identifiers <r. a. passwords! which through legal or illegal 
channels may become known- to others, thereby allow- 
ing unauinoraed access -to these databases. 

Prior art mechanisms for handling such security 
concerns have not taken advantage of advances m 
communications and computer systems to automate the 
alerting and approval process. Mosf techniques which 
have heretofore attempted to address these security is- 
sues tend to significantly increase the complexity of the 
communication protocol Par example, the customer 
may be asked additional questions- (the answers to 
which it is expected that only the authorized party would 



know}, or may be required 10 provide additional informa- 
tion as a part of each transaction such as a {secret} Per- 
sonal identification Number (PIN). Moreover. » may be 
required that such PINs be modified on a routine basis 

$ in order to maintain their sec recy To encourage custom- 
ers lo make use of these types of services , credit 
and calling cards}, it has become common to limit the 
liability of fhe customer while increasing !he liability of 
the service provider (e.g., the credit card vendor or tel- 
le aphone company). Unfortunately, unauthorized uses 
usually go undetected until a periodic service report is 
issued -- typically, at the end ot a monthly biting cycle 
and Song aftet the fraud was perpetrated. 

In addition to fhe above -described security issues, 
one commonly desired class of financial t ransactions in- 
volves a principal who empowers an agent to initiate and 
complete routine transactions without the principal's 
knowledge or approval. However, the principal often re- 
setvesthe ngh! tobe alerted to. or even to approve, such 

*> transactions, particularly when they are idenliliabiy non- 
routine or atypical, For example, approval may be re- 
quired when certain threshold parameters that are as- 
sociated with the transaction (which may, tor example, 
be pre-defined by the principal) are exceeded. 

as Prior ah mechanisms tor handling such agent initi- 
ated transactions have afso not taken advantage. of ad- 
vances in communications and computer systems to au- 
tomate the alerting and approval process, thereby lim- 
iting the scops of applications of such transactions. For 

& example, a card owner, such as a corporation (parent) 
thai provides an employee (young adult) with a credit/ 
debit card to charge business {personal) expenses, -typ- 
isaiiy places certain restr ictions on the use of the card 
by. the cardholder fo preventabuses. excesses or traud. 

s& Those restrictions include, tor exempts, upper limits on 
either the total amount of money that can he charged to 
a commercial credit card, or the number ot transactions 
that can be authorized for a credit card number within a 
predetermined period of time. Those restrictions some- 

-w times operate to deny access to credit fo a cardholder 
who is stranded or facing an emergency situation, when 
ironically credit is most needed This clearly dot eats the 
purpose of empowering the employee or young adult. 
Yet, oversight of the use of those credit car ds by the card 

*s. owners is still needed since the card owners are ulti- 
mately tinanaaSJy responsible for She expenses charged 
to those ciodii cards. This issue takes particular signif- 
icance when one considers thai merchants concerned 
about lack of legal competency o? minors to complete 
card transactions have been reluctant lo accept debit or 
credit cards as a means ot payment from minors. Hence, 
another specific problem ot the prior art- is tack, of a flex- 
ible restnetiun median ism for principals- to limit monitor, 
and.'Of approve use of a card by cardholder for non-rou- 

«s tsne commercial transactions. 
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Summary of the invention 

We have recognized that the aforementioned prob- 
lems result trom the inability to quickly and efficiently in- 
form the individual customer fag,, the account holder 
of fhe principal) that nls or her customer identifier (e.g. , 
credstfctebftteaiimg card number, PIN. password, efc. ) 
» besng used in a transaction for a particular purpose, 
and the inabsiity oi She customer so respond thereto in 
order to confirm or deny sts use. Thus, in accordance 
with certain illustrative embodiments of the present in- 
vention, anautomafed method tor authoring a trans- 
action is provided in which the customer is informed of 
a pondsrvg authorization thereof, and the- transaction is 
then authorised only in response to a customer confir- 
mation, in accordance with certain other illustrative em- 
bodiment, the invention provides a method and a sys- 
tem which aliow a principal to be automatically alertec' 
to. and/or to promptly authorise, an agenHnftiated 
transaction which may. lor example, be deemed atypical 
based on a pre-etored profits specified by the principal. 

In accordance with one illustrative embodiment, a 
request so authorise a transaction is received: wherein 
the request includes a customer identifier; a determina- 
tion is made whether so authorize the transaction based 
on the customer identifier; i! the determination is made 
to authorize the transaction, the pending authonzstion 
is -communicated to the customer: a confirmation that 
the transaction is. in fact, to be authorized is received 
bacK from the customer: and the transaction is autiior- 
ized-in response to the customer's confirmation thereof. 

One approach to communicating such a determina- 
tion to authorize the transaction and to receive such a 
confirmation to authorize tram the customer is illustra- 
tively afforded by conventional two-way pagers. For ex- 
ample, a computer database, charged with the task oi 
authorizing a transaction, may signal the customer via 
paging whenever ins or her customer identifier is used. 
Along with this notification, relevant information may be 
displayed on the pager -S alphanumeric (or numeric; dis- 
play. The customer may then respond (via the two-way 
pager} by confirming or denying the pending authonza- 



to authorize/deny the charging of the: 
card number by transmitting an approval/disapproval 
message to the card issuer as past of ate card validation 
process 

According to another aspect of the invention, a mer- 
chant may request the approval of a parent or guardian 
to a. debit/credit card transaction, such as a stored-vatuo 
smartearS, presented to the merchant by a minor siieg- 
sng to act on behalf of the parent or guardian. In that 
case, the card number, or a proxy thereof, may be used 
as a search key to retrieve the parent or guardian's pro- 
file that identities a communeaf ions address for the par- 
ent or guardian. The transaction is approved only II an 
authorization message is received from the parent or 



Brief Description of the Drawings 

FIG 1 is a telecommunication system arranged in 
accordance with the invention to - allow a card owner So 
authorise, or to be a leried to transactions charged to the 
card by a cardholder 

FIG. 2 illustrates an exemplary message that 1 is 
transmitted by an automatic dialing unit at a merchant's 
location to a card issuer's validation database. 

FIG. 3 shows an illustrative table that associates 
alerting threshold parameters to card numbers. 

FIG 4 shows an iilusiraSive generic message that 
is transmitted by an automatic dialing unit at a mer- 
chant's location to a card owner's communications ds- 

FiQ. 5 shows specific exemplary messages thai 
may Pe transmftSed by a card validation system to a card 
owner's communications device. 

FIG. 8 is a fable that correlates merchant codes to 
types of commercial establishments. 

Ft 8. 7 shows a flow diagram outlining ii lust rati vs 
programmed instructions executed by different ele- 
ments of the communications system of FIG. 1 to re- 
ceive approval for. or to alert a credit card owner so, a 
credit card transaction initiated by a card holder in ac- 
cordance with certain illustrative embodiments of the 



According to one aspect of the invention, exception 
conditions that trigger a customers alerting or approval 
process may be stored in a profile specified by the cus- 
tomer. This profile associates those exception condi- 
tions to a personal communications .address, .such as a 
paging number or a "'300° or "700" prefix telephone 
number at which the customer can be reached. For 
credit/debit and casino, card transactions, exception 
conditions may be caused, for example, by a request for 

old parameters pre-tmposed by the card owner for the 

use of the card, or breach of other conditions pre-de- 
fined by the card owner for the use of the card, in ac- 
cordance with the principles of the invention, the card 
owner may elect to simply receive the alert message or 



FIG 8. is a fiow chart o! illustrative programmed in- 
structions executed by various components ot the com- 
munications system of FIG. 1 to receive approval from 
a parent or a guardian of a minor initialed debit card 
transaction in accordance with a first illustrat ive embod- 
iment of (he present invention. 

FIG 9 shows a flow chart ot a credit card purchase 
transaction to which certain illustrative -embodiments ot 
fhe present invention may advantageously be applied. 

FIG. ID shows allow chart of an authorization proc- 
ess in accordance with a second illustrative embodi- 
ment of the present invention. 

FIG 11 shows a flow chart of an authorisation proc- 
ess in accordance with a third illustrative embodiment 
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FIG. 1 2 shows a fiow chsm of an authorisation proc- 
ess in accordance with a fourth Niustralive.embodtmsof 
of present invention. 

FfG. 1 3 stows a tov chars of a credit card purchase 
transaction to which a fifih illustrative embodiment of the 
present invention may advantageously be applied. 

FIG. 14 shows ;a f Sow chart oi an authorization proc- 
ess In accordance wish a ftfth iBustrattve- embodiment oi 
the present invention. 

.^ta||ed_OeacrJgtlon 

Introduction 

Although the principles elihe present invention may 
be applied to many domains; the iterative embodi- 
ments described in detail herein focus on a credit 
card or debit cars purchase transaction. In these em- 
bodiments, a cardholder who may or may not be the 
customer of the credit or debit card issuer, uses a credit 
or debit card tor a credit card number} to instruct a re- 
tailer {a prowler ot a product or service} to charge a 
purchase to the given credit card account or io debit the 
amount of the purchase from the given debit card ac- 
count The credit or debit card number serves as a cus- 
tomer identifier to the credit card service provider te g., 
the issuer of the credit card}. 

Ft£3. i shows a corn munioat tons system arranged 
in accordance with certain illustrative embodiments oi 

of.' The communications system of FIG. 1 includes a 
communications network 102, a validation database 
1 08 and a paging system network 1 1 1 Communications 
network 102 includes one or a series of interconnectect 
communications switches arranged to relay to validation 
database 106 (via lines t30-1 to 100-N information re- 
ceived from card reader 101. Specifically; when a credit 
card holder hands a credit card to a merchant to char ge- 
expenses associated with a transaction, the merchant 
slides the credit card through caret reader 101 to react 
the credit card number, for example, off the magnetic 
stripe on the back of the credit card. An automatic dialing 
unit included in card reader 10! dials a telephone 
number associated with a database 106 of the card is- 
suer to validate the card number, in particular, card read- 
er 101 transmits to validation database 108 a validation 
request message that is illustratively represented in 
FIC3. 2 

Similarly, when the cardholder washes to use adebit 
card such as an Automatic Teller Maehme {ATM} card 
as a means ot oaymsnt for a commercial transaction, 
the merchant enters a special code Into card reader 1 0 1 
to initiate the alerting and approval process. Thereafter 
card reader 1 01 retrieves the debit card number, tor ex- 
ample, from the magnetic stripe on the back ot the debit 
card before prompting the .cardholder for a secret code 
!'&<?. , a PIN}, Card reader toi then transmits to valida- 
tion database 1-0-1 a validation request message that ts 



illustrated in FIG, 2. 

The massage shown « FIG. 2 includes a card 
number 201 . a requested credit amount 202. a merchant 
code 203, and a validation request 204. When card 

$ number 201 is a debit card number, it also includes the 
PiN entered by the cardholder. Merchant code 203 is a 
field that identifies the type oi business from which the 
message associated with the transaction, ts transmitted 
Typically, the merchant code 203 is appended by card 

if reader 101 after the requested credit amount 202 has 
been entered by the merchant, and the calling card 
number £01 has been retrieved from the magnetic strips 
on the back o! the card. The validation request field 204 
stores the code entered by a merchant to receive ap~ 
provaf f rom she party authorized v> give such approval 
for a debit card transaction. In the case where the card- 
holder ts a minor, for example, by requesting approval 
of the transaction from a parent or guardian of the minor 
fi.e., fhe authored parly}, the merchant and the debit 

*> card issuer are assured that the transaction cannot ce 
voided by the- min or at a later date on the ground that 
the minor lacked legal competency to enter into such 
transaction 

Upon receiving a validation request message, van* 
as datian database t OS uses card number 201 as a search 
key to perform a tabfe ioots-up operation for tne purpose 
of retrieving the profile associated with fhe card number- 
When the cardholder Is a minor, and the card is a slored- 
vaiue smartcard. a passphrase or proxy information pro- 
's? vsfed by the minor may be usedasssareh key to retrieve 
the profits of FIG. S 

validation database 1 06 is a processor-controtted 
centralized database facility wnlch is a repository of 
records or profiles tor ail credit/debif card numbers as- 
s& signed by a card issuer to its -customers. Validation da- 
tabase 106 is designed to authorize transactions 
charged to card numbers stored therein. Such authori- 
zation may be based on a set oi pre-defined parameters 
included in the profiles associated with the card num- 
-w bsrs. When a retrieved proiite does not include a re- 
quirement ior alerting or approval, validat ion of the card 
number may be performed in a conventional manner 
When a profile stores alerting parameters that may re- 
quire communications with one or more called parties, 
45. validation database 108 uses one of the Automatic Or- 
ating Units fAOU) 110-1 to 110-N to dlat a telephone 
number retrieved from a profile associated with a card 
number. 

Shown in FIG, 3 is an illustrative tabfe that associ- 
■Sf ates alerting and approval ih reshoid pasamets rat .to cred- 
it card numbers. Each record in the fable of RG, 3 is a 
profile for a credit card number that is used to determine 

card number are processed. The table ot FfG. 3 includes 
«s a cardholder's name ftsid 301 ; a card number field 302.. 
alert and authorization flags 303 and 304. respectively; 
a trigger group ot fields: a communications address field 
307: a ncranswer-credtt threshold field -309; and a no- 
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.answer-transaction threshold tieid- 310. Cardholder's 
name field 301 stores the' name oi a card holder asso- 
ciated wfttt a particular card number. The cardholder's 
name fietd may contain, tor example, She first and last 
name of she cardholder fas shown for the first and third 
record) or ill's test name {or nickname} or the cardholder 
{as shown for the second and Jouith record). Credit card 
number 302 is used as a search key in the sable lookup 
operation mentioned above, to retrieve the profile asso- 
ciated wttn mat card number. The aiert flag field 303 in- 
dicates that the card owner ta to be notilted. although 
possibly only under certain conditions Such notification 
may be required, for example, when processing of iha 
transaction would either causa certain conditions pre- 
defined tor the use ©l the card to be breached, or a 
threshold parameter to be exceeded. The approval Hag 
field 304 alerts fho card issuer that credit card transac- 
tions that violate pre-estabiished conditions need to he 
authorized by the card owner as part of the card valida- 
tion process. These ore-established conditions may be 
pfe-safected by the card owner or they may be condi- 
tions imposed by the card issuer. The trigger group of 
fields depicted in FIG. 3 illustratively shows different pa- 
rameters when cause a card owner to be notified when 
those parameters exceed certain pre-defined thresh- 
olds The "conditions" field 305 shows restrictions pre- 
selected by the card owners for use of their credit cards. 
For exa m pie, t h a firs! record indicates that the card own - 
er wishes to fie alerted whenever a cardholder charges 
more than one hundred f 100) dollars to the credit card 
number. The third record illustrates that the card owner 
wishes to authorize any credit card transaction for more 
than three hundred dollars. By contrast the owner of the 
credit card number associated with the third record 
wishes to be alerted whenever that card is used at com- 
mercial establishments associated with specific mer- 
chant codes. Some card issuers assign distinct mer- 
chant codes to commercial establishments, such as 
bars, hotels and liquor stores, thereby allowing credit 
card transactions at those establishments to be easily 
identified. 

Other restrictions trial may be Imposed by a card 
owner may include, for example, the "maximum number 
of transactions* field 306 which defines an upper limit 
on the number oi transactions that can be charged to a 
credit card number within a predetermined period ot 
time. For example, the second record indicates that the 
card owner's- approval ts -required to validate a credit 
card .transaction when more than three credit card trans - 

number within a - twenty --'our (24! hour parted. Such a 
condition may be useful for example, in detecting fraud- 
ulent use of' a. stolen credit card. When a transaction 
threshold number ss used as a parameter tor processing 
a credit card transaction, the transaction counter field 
307 is incremented by 1 {one} every time a credit card 
transaction is processed, "Hie transaction counter field 
307 is reset to "0" alter (he ■predetermined period fag.. 



24- hours} has ■ expired, ItwiH be appreciated that only a 
limited number oi restrictions and/or authorizations are 
shown in FiG. 3 tor ease of explanation, even though 
many other restrictions, obvious to those of ordinary steli 
tn the asf , may be requested by card owners or card Is- 
suers lor inclusion in the profile ot FiG. 3 

Whenever a card owner is to be notified ot a condi- 
tion-breaching credit card transaction, the communica- 
tions address fteid 308 may be used to identity a tele- 
phone number or an electronic mail address at which 
the card owner can be reached. Preferably, the commu- 
nications address field stores a pager number associat- 
ed with a communications earner which provides paging 
service on a nationwide basis to contact, for example, 
the card owners associated vwth the first and the ■ fourth 
record. Alternatively, a personal telephone number, 
such as a "600* or a "700" prefix number may be used 
as a reach number for a card owner such as the card 
owner associated with ihe second and third record 
shown in FiG 3. As another alternative, an electronic 
mail address may be used which, in various illustrative 
embodiments., may be either an address to which con- 
ventional electronic mail may be sent or an electronic 
address for use in other forms of electronic signaling 
such as. for example, a direct message communicated 
to she computer screen o! a logged-on user or an inter- 
active electronic .two-way common teat ion mechanism 
fag., a "chaf or talk" program). 

Also included m the profile of FIG 3 is no-answer- 
eredit threshold fseld 309 and no-answer-transaction 
threshold field 3t0. Those -fields identity respectively, 
the maximum amount of credit that can be approved, 
and the maximum number o! permissible transactions 
within a given period of time, when the card owner can- 
not be reached by the communications system of FIG. 
1 When the card owner does not wish any transactions 
to be authorized when he or she cannot be reached, 
then those tiefds are set So zero. 

When ihe cost associated with the commercial 
transaction is charged to a debit card, as opposed to a 
credit card, onfy the card holder's name field 301, the 
card number field 302 and the communications address 
field 308 are of particular relevance since the request 
for approval is initiated by the merchant and the com- 
merciaf transaction is not completed when the debit card 
holder cannot be reached. 

Ref erring back to FfG. t , when a. transaction re- 
quest massage, such as ihe one illustrated tn FiG.. 2:, is 
received by validation database tOS. the latter uses a} 
the information included tn that message, and bj the re- 
trieved profile associated with the card number in that 
message to determine whether at least one card owner 
pre -imposed condition has been breached {or a card 
owner pre -defined threshold has-been exceeded), if so. 
validation database 108 fetches the communications 
address of the credit card owner and any other appro- 
priate information to format an authorization request 
and/or -alert message that is transmitted to the card own- 
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sr. One such massage is illustrated in FiQ. 4 which 
shows a card header's name field 4Ql,s display field 402 
and a Sfetd 403 that is populated by an entry tn the table 
illustrated irt FiQ, 5. Tnecard holder's name-is populated 
by the name that is included in the profile retrieved in- 
validation database 108. Field 402 is a display field that 
always contains the two words "Credit Caf es ' 1 Held 403 
« populated by on® of the entries in fha table of FiG. 5. 

The tabte of FIG. S shows three separate entries 
50t. 502 and 503 representing different sections of 
three different messages. Each entry is comprised 
mainly ot display information and one field that is popu- 
lated based on the particular condition that has been 
breached or the specific threshold thai has beers ex- 
ceeded. For example, when the requested credit 
amount lor the transaction exceeds the charging limit 
pre-selected by the card owner, field 505 wt« fee popu- 
lated by she difference between the maximum charging 
ariioun! and the requested credit amount. Similarly, 
when validate} of a card number for a transaction would 
cause she maximum number' of transactions per day 
ore-selected by the card owner to be exceeded, the con- 
tent of Ihe transaction counter field is moved into field 
506. Likewise, when ihe card holder attempts to charge 
to a credit card number the expenses related to the pur- 
chase of an item from a commercial establishment that 
is associated with a prohibited merchant code, that code 
is translated so one of she establishment type entries 
shown in ihe fable ot FIG. 6. That tabte correlates each 
merchant cods to a particular type of commercial estab- 
lishment; For example, hypothetical merchant code 
1 234 is associated with liquor stores, while fictitious 
merchant code 458? is mapped to hotels and motels. 
Thus, once a merchant cocte is to a commercial estab- 
lishment type entry, that entry is simply copied to field 
507 of FIG S. 

By populating Beid 403 of FIG. 4 with one of ihe en- 
tries in FIG. 5; a complete message is formulated tor 
transmission to the card owner. Thereafter, validation 
database 108 retrieves the communications address in 
the profile to send to the card owner the message illus- 
trated in FIG. 4 via an (die automatic- dialing unit selected 
from ADU 110-1 to ADU n0«N. The tetter are arranged 
a) to initiate phone calls by dialing telephone numbers 
received tram validation database 1 08 and: b i to bridge 
those calls to other communications devices upon de- 
tecting a feedback signal from the card owner. ADU 
110-1 to ttO.-N areaiso designed to terminate the rail I! 
no feedback signal is received after a predetermined pe- 
lf the communications address Is a persons tele- 
phone number, such as a ""500* or "700* prefix number 
(shown, for example, in the third record of FIG 3), then 
database 108 transmits the message illustrated in FiG. 
4 So interactive Voice Response System {-IVBS} 125 be- 
fore sending the communications address of the card 
owner to an idle AOU. Upon receiving the number dialed 
by AOU 110-1, tot example, communications network 



•502- translates the- W or "700" pre 
number to a Plain Old Telephone- Service (POTS) tele- 
phone number at which the card owner can be reached. 
When ADU 110-1 detects a feedback signal from the 
card owner, if bridges the call (via line 140) to interactive 
Voice Response System (IVRS) 525 thai delivers the 
message of FiG. 4 in audio form to the card owner at 
telephone set 145, for example Specifically ivRS 125 
ts a pieeessor that executes ie*i-to-speeeb synthesis 
programmed instructions designed to use ASCII Input, 
such as one of ihe messages shown m FIG. 4; to gen- 
erate a "read aloud* audio rendition ot that ASCII input 
in a -machine synihesized voice. IVRS 125 is also ar- 
ranged fo prompt a card owner to provide some input to 
approve or disapprove a particular transaction. For ex- 
ample, a card owner may be prompted to enier a "1 * on 
a telephone dlalpad to -approve a transaction, or a *2 h 
on the dislpad fo disapprove the transaction. Atso in- 
cluded in IVBS 1 25 is a means to respond fo touch-tone 
commands from a -caller . in particular. IVBS ;25 is ar- 
ranged to translate the Dual Tone Mufti-Frequency (OT - 
MF) signal received from the card owner to a machine- 
readable format,- such as ASCII, that is recognisable by 
validation database 108, Alternatively. IVRS 125 may 
include a word recognition untt thai is arranged to output 
digitally recorded words, such as the messages In FIG 
5. to prompt a card owner tor particular inf ormation that 
is converted to ASCII format for delivery to validation 
database 108 Furthermore, in order fo insure that the 
person approving the transaction is the card owner, as 
opposed so an impostor. IVRS 125 may atso include a 
speaker recognition unit that stores templates of pre- 
recorded digitized voice messages of the card owner 
that are compared to any input received from the catted 
party to certify that the "real* card owner is the person 
approving the transaction. 

it the communications address is a paging tele- 
phone number, then one of the AOUs 110-1 So 110-N 
dials the paging telephone number to initiate a call to 
that paging telephone number for the purpose of deiiv- 

of thVcard owner. The call' is routed over communica- 
tions network 502 which uses one ot ihe demodulators 
1 20-1 to 120-N to SransfGim the received message into 
proper signaling format for delivery to paging system 
network l n which may be. tor example, a sateline- 
oased nationwide paging service network, Alternatively, 
paging system network 1 1 5 may be a cellular communi- 
cations network or a Personal Communications Servic- 
es (PCS) network. Paging system- network HI includes 
a base station (not shown} that receives the dialed 
number along with the message of FiG, 5. The base sta- 
tion tnen sdsnhfies a particular frequency associated 
with thai paging telephone number to code the received 
message as a series of pulses i ©presented by a carrier 
that i s moriu la! ed on that f requ ency for delivery to pager 
1 36. The latter converts the pulses into a series of bytes 
representing the message ot FIG. 5, Thereafter, pager 
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135 emits a loud beep to signal the card owner of an 
incoming message Alternatively, pager 1 35 could be 3 
vibrating pager which silently alerts the card owner ot- 
itis incoming message through a vibration .signal gen- 
erated therein « response to the reception of a mas- 
sage. 

When the incoming message is an alert signal from 
validation database 1 0S. pager 1 36 can be any commer- 
cially available paging device with a smalt screen tor dis- 
play ing She message of FIG, 4. Howevei. i! art approval' 
disapproval response is requested by validation data- 
base : Q8, pager 1 08 may advantageously be a two-way 
paging device, such as the device available from Mobile 
Telecommunications Technology inc. of Jackson. Mis- 
sissippi, in thai case, the card owner transmits an ap- 
prcvai/disappraval message by entering a pre-defined 
code in the two-way pager. The pre-defined cafe is fhe-n 
transmuted to validation database 106 via paging sys- 
tem network ill. The pre-defined code is received by 
one of tne demodulators 120-1 so 120-N which demcd- 
uiatas the signals associated with the- received code for 
presentation to validation database 106. Alternatively, 
pager 135 may be a one-way pager, in this case, if an 
approval/disapproval response is requested by valida- 
tion database 108, the card owner may communicate 
m approval/disapproval message to validation data- 
base 108 by other means, such as with use of a con- 
ventional telephone, for example. 

A first illustrative embodiment 

FIG. 7 shows a flow diagram m accordance with cer- 
tain illustrative embodiments of the present invention 
outlining programmed instructions executed by differ ent 
elements of the communications system of FiQ. 1 to re- 
ceive an approval from a credit card owner for or to alert 
a credit card owner of. s credit card transaction initiated 
by a card Holder. The process shown in FIG. 7 is initialed 
instep 701 when validation database 108 receives a val- 
idation request tor a credit card number. As mentioned 
above, the request for approval may be secaivsd in She 
form of a data message, such as the one illustrated in 
FIG. 2. Upon receiving 1-hsetedit card number, validation 
database 106 uses the received credit card number as 
a search key in an attempt to retrieve a profile tor the 
credit card number, if no profile- is available in the vali- 
dation database for the credit card number as deter- 
mined in step 702. validation database returns an "un- 
authorized transaction" message to card re-adei 101 via 
communications network- 102,, When validation data- 
base f 08 is able to retrieve a profile for t he card number, 
the profile is analyzed in step 704 to determine whether 
the requested credit amount or the type of transaction, 
for example, triggers any alerting or request for approval 
conditions, if no such conditions are triggered, validation 
database 106 proceeds with lbs validation process ins 
conventional manner. Otherwise, m step 706, validation 
database 1 06 ascertains whether the card owner is only 



to be alerted when the pre-defined condition Is encoun- 
tered. If so, validation database 108 retrieves from the 
profile the card owner's communications address to 
which the alerting message is sent, as indicated in step 

$ 707. Thereafter, validation database >06 proceeds with 
the validation process in a conventional manner. 

When the profile retrieved by validation database 
1 06 indicates that the card owner is to approve the credit 
card transaction {such as the one requested by the card 

if holder) validation database 1 06-fGrmuiat.es a request for 
approval message (using appropriate entries in FIG. 4 
and FIG. 5) -or ■transmission to the caro owner, as indi- 
cated In -step 708. As mentioned above, the request for 
approval message may be delivered In fhe form of a tel- 
ephone call or a paging message. After the transmission 
of- the message, validation database waits for a re- 
sponse from the card owner. When validation database 
determines, in step 709,. mat no response is forthcoming 
after a pre-defined period of time has expired, validation 

*> database 106. in stop 711. assesses whether Ihe re- 
quested credit amount exceeds the no-answer-credit 
threshold. As Indicated earlier, the no-answer-credit 
threshold is a field in the profile for a card number which 
stores the maximum amount of credit that can be ap- 
proved tor a credit card transaction when the credil card 
owner cannot be reached by the communications sys- 
tem of FIG. l. ff the requested credit amount exceeds 
the no-answer-credit threshold, aa determined in step 
7ii. then validation database 106 returns an "unaufhor- 

& teed transaction" message to card reader 101, if the r e- 
quested credit amount does no) exceed the no-answer- 
credit threshold, the content oi the transaction counter- 
field in the profile is compared to the no-answer-trans- 
act ion th reshold to determine whether this threshold has 

s& been exceeded. If so. validation database 106 returns 
ars invalid card message tocard reader 101 . as. indicated 
in step 70S, if neither oi the no-answer-shresholds has 
been exceeded, validation database 1 06 completes tha 
validation process in a conventional manner, as tndieat- 

-w edin step 703. 

When validation database 106 receives a response 
from the card owner within a pre-defined period of time, 
as determined In step 709. validation database 106 then 
assesses whether the response indicates approval ot 

45. the transaction by the card owner If so, validation data- 
base completes the validation process in a conventional 
manner, as Indicated in .step 70S. Optionally, the card- 
holder may be- required to provide a secret code that 
matches a similar code included in the response re- 
st 1 solved from the card owner before the transaction is au- 
thorised, if a disapproval response is received from ihe 
card owner, validation database 108 returns an 'unau- 
thorized transaction'' message to card reader 101. 
FIG. 8 is a flow chart outlining instructions per- 

«s formed by the elements of the illustrative communica- 
tions system of F!t3. 1 to validate a debit card transaction 
in accordance with a first illustrative embodiment ot the 
present invention. The process depicted in FIG. 8 is in- 
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Stated «i step 80 s wherr validation database 106 re- 
ceives a debit card numeer and a password entered by 
a msnor card holder. Validation database tos launches 
a query on its storage devices to determine, in step 802, 
whether a profile can be retrieved fonhe received card 
number, if no profile is found, validation daiaaase 108 
transmits an "trooihcsrized transaction ° message to 
card reader 101 . as indicated m step 803. Upon retriev- 
ing a profile for the card number, validation database 
1 06 formulates a message using oris of the -entries of 
RS. 4 for transmission to the card owner Thereafter, 
validation database 106 mm a pre-defsned amount or 
time to determine whether a response ss received from 
the- card owner, If fhe pre-defined amount of time expires 
before a response is received from the card owner, val- 
idation database 106 returns art "unautoized traosao- 
lion* message to card reader 101 . as indicated in step 
SOS. When a response indicative of the card owner's ap- 
prove! of the transaction ts received from the card owner, 
as determined in step 806. validation database 106 pro- 
ceeds with, the vaftdation process in a conventional man- 
ner, as indicated in step 807. if the card owns; sends a. 
message disapproving the debit card transaction, vali- 
dation database 108 sends an "unauthorized transac- 
tion" message to card issuer 1O1. as indicated m step 
80S. 

frt other jfiuslrative embodiments ot the present in- 
vention, the autfiorfeation of a transaction may need to 
be approved by more than one party. For example, it the 
charge account is a corporate account and the amount 
of the charge; is ever a certain predefined llireshoid, if 
may be required that two authored parties (e.g., cor- 
porate executives) approve the transaction. This is anal- 
ogous, for example, to the common retirement that 
corporate checks over a certain amount (e.g.. Si ,000! 
include two authorized signatures to be valid Similarly, 
i! the transaction -involves, tor example, the dispensing 
of medications tn a hospital i'see below), it may be de- 
sirable that both the patient's doctor and the hospital's 
pharmacist approve the treatment. In these cases, step 
806 of Ff G, 8 is modified to determine whether a| parties 
which are required to approve the transaction have done 
so, 

A second iliustretive embodiment 

FSQ. 9 shows a flow chart of a credit card purchase 
transaction to which certain illustrative embodiments of 
the present invention may advantageously be applied: 
The transaction is Initiated by a cardholder , the cus- 
tomer} who instructs a retailer to charge a purchase to 
a given credit card account (step 11 1. "0'iis instruction 
usually takes the form of providing a credit card or a. 
credit card number to she retailer. This transaction may 
occur with the customer and the retailer co-piesenf and 
in real-lime, white the customer is waiting, tn this case, 
the timeliness with which the authorization process ss 
completed is ciaarly ot great importance, since the rel- 



evant parties are awaiting such authorization .before 
they may proceed with other endeavors. (For example, 
fhsy may be wasting so that the retailer may hand over 
the goods to the customer or provide a service thereto, j 

$ Thus, the communication to the customer and a confir- 
mation or denial of authorization by the customer should 
advantageously occur quickly. For this reason, the use 
of two-way pagers is preferred lor this type of application 
of the principals of the present invention, 

io in alternative- applications, the customer may have 
instructed the retailer for an agent os the retailer) in per- 
son or via some communication mechanism (e.g. . a 
phone, mail, -facsimile or eiectromc mail} at a time prior 
to the initiation of the transaction. Such instructions 
might cover an immediate one-time purchase, a future 
purchase (e.g., the goods or service may not be imme- 
diately available) or a series ot purchases to occur over 
a period of Htm. In cases such as these where the cus- 
tomer and the retailer are no! co-present, the parties 

*> moss typically do not require the authorization so be com- 
pleted before they may proceed with other endeavors. 
Thai is, is may be acceptable in these cases that the au- 
thorization process be complsseo over a longer period 
of time such as, for example, several hours or -even a 

as day.. In these cases- therefore, other foss Immediate 
communications mechanisms may be used, such as 
those provided by conventional telephones, e-mail. or. 
in some circumstances, even physical mail 

sn any event the retailer's typical response to such 

•3<? instructions ts to signal a transaction processing center 
for a network of such centers! which is associated with 
the credit card service provider that a particular custom- 
er (identified by his or her credit card number) wishes to 
purchase goods or services of a particular value Thus; 
the retailer requests an authorization torthe charge from 
ft it. tfriu&fcio' c Ov essing rente! >etcp 12) Typc.slty 
this request is initiated by swiping me credit card through 
an automated card reader (such as card reader 101 o! 
FIG. V> which reads the magnetic stripe on the credit 

-w card, dials the transaction processing center, sends the 
relevant information thereto and receives either an au- 
thorization code or a denial In response therefrom. The 
information transmitted to the transaction processing 
center typlcatiy includes the credit card number, the 

*5. amount of f he contemplated purchase, and the retailer's 
store identification code (e.g., card number £01. re- 
quested credit amount 202, and merchant code 203 of 
FIG. 2. respectively). The retailer then waifs for art au- 
thorization f rom the transaction processing center which 

■Sf represents that the charge will be under written rr.e., in- 
sured) by the credit cad service orovlder. This authori- 
sation is typically sent to the retailer m She form of an 
authorization code which identifies the transaction and 
can thereby be used to verify thaf the authorization prec- 
is ess was properly adhered to by the retailer. One typical 
reason for denial, on the other hand, is that the balance 
on the customer's account has exceeded {or if the given 
purchase were authorized would exceed) a predeter- 
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mined creeps limit associated with the customer's ac- 
count in accordance with certain illustrative embodi- 
ments ot present invention, another reason for dental is 
the lackof the receipt of an appropriate confirmation (or 
the receipt of an expiieif denial) by the customer whose 
account is Jo be charged. 

At Ihe transaction processing center, the -authoriza- 
tion process is performed automatically by- a computer 
based system comprising, mt&ralia. a database (e.g., 
validation database t06 of FiG. i) containing account 
information for each credit card subscriber (step 1 3). 
Thai is. such a system automatically makes the decision 
whesher to authorize or deny the transaction « no hu- 
man intervention is typically required at ihe iransacuon 
processing center, ft ths transaction is authorized (de- 
cision 14}. as is typscsEy Indicated by the appearance of 
the authorization cods on ihe display of the retailer's 
card reader, the retailer is thereby authorized by the 
credit card issuer to accept the charge tot ihe purchase. 
Thus, the charge is accepted and ihe transaction is com- 
pleted (step 15). It, on the other hand the transaction is 
dented by the transaction processing center i'iypicaily 
indicated by the appea rance of a denial code on the card 
reader's display), the retailer denies ths charge and ter- 
minates ihe transaction tstep t6). 

FSS 10 shows a flowchart of an automated author- 
ization process which may be used to implement step 
1 3 of the process of FiG. S in accordance with a second 
illustrative embodiment of the present invention. The 
process ot FIG. 10 is illustratively executed by a com- 
puter system at the. transaction processing center « re- 
sponse to each received request for the authorization of 
a transaction. The received authorization request {typi- 
cally transmitted by an automated card rsaderai the re- 
tailer's location such as card reader 101 ot FiG. 1) in- 
cludes, in particular, a customer identifier p.a , the credti 
card number) and may: for example, also include the 
amount of the proposed purchase and the retailer's 
store identification code {step 20}. Based on fhe cus- 
tomer identifier, -a database (such as validation data- 
base 106 of FIG, 1 } is consulted to determine whether 
the transaction should be authorised (steps 21 and 22). 
For example, the database may sncfode account bal- 
ance and credit tirnii information indicating that fhe cus- 
tomer's account balance is not permitted to exceed a 
given credit limit in such a case, the system will deter- 
mine thai the transaction should not be authorized if the 
sum of the account balance' and ths -amount of ihe pur- 
chase to be authorized exceeds ihe credit limit fo addi- 
tion, invalid or- (known to be! stolen credit cards obvi- 
ously shouid not be authorized. 

f! it is determined' from the analysis o! step 22 that 
ihe purchase should no! be authorised for same reason 
(decision 23), the system will format a dene! coca (step 
24}. If - on the other hand, there is no basis for denying 
the transaction, ihe system wilt, in accordance with ihe 
principles .©? the present invention, make an attempt to 
have the (tentative! authorization confirmed by the cus- 



tomer, in particular, and in accordance with a second 
illustrative embodiment thereof. Ihe system wii auto- 
matically page the customer fusing, tor example pager 
1 35 oi FiG. 1 j, supplying to him or her any relevant in- 

$ formation concerning the purchase {step 25 1. For exam- 
ple, the system might supply the customer with an iden- 
tity of the r staffer and/or fhe amount of the purchase, in 
order to enable the customer to mora accurately ensure 
that ihe transaction to be authorized is. m fact, fts one 

if he or she is presently undertaking, or. alternatively, that 
fhe transaction Is one feeing undertaken by an agent and 
the principal r'r.e.. the customer) approves thereof. Ths 
customer's pager number f'te.,. She telephone number 
which is used to communicate with the pager) may, for 
example, be stored m the database and associated with 
the customer's account, as is shown irs FiG. 3. 

Once ihe customer has been paged, ihe system of 
the second illustrative embodiment waits tor a eoniirma- 
tion from the customer which may he supplied wish use 

*> ot fhe customer's two-way pager (step 28). if the cus- 
tomer responds with an appropriate confirmation (deci- 
sion 27). the system generates, formats and stores an 
authorization code which will enable the transaction to 
be completed it. on ihe other hand, fhe customer does 

as not confirm the transaction (e.g , ti no response is re- 
ceived from the customer within a predetermined 
amount ot time), the system formats a denial code (step 
24}. Afier either a denial code or art authorization code 
has been formatted, if is sent to She retailer (a g.. , io card 

•3<? reader 101 of FIG; 1} who originally submitted the au- 
thorization request {step 29) 

A Third illustrative Embodiment 

s$ FIG . 11 shows a flow chart of an automated author- 
ization process which may be used to implement s;ep 
13 ot the process of FIG. i in accordance with a third 
iiiustrative embodiment otthe present invention. As can 
be seen from the figure, the illustrative process of FIG 

-w 11 is tdenticai to fhe illustrative process shown in FIG. 
10 except that -decision 27, whtch determined whether 
a contjrmatjon was received from the customer is re» 
placed by decision 30. which determines whether a de- 
nial is received from the customer Oilier embodiments 

45. ot ihe present invention may combine those shown in 
fig. to and FIG. it by accepting either a confirmation 
or a denial from the customer, in such a case, the default 
rt.a, timeout) criterion may be either an assumed con- 
firmation or an assumed denial. 

A Fourth lifusfretive Embodiment 

FIG. 12 shows a. flow char! of an authorization proc- 
ess which may be used to implement step 1 3 of the proc- 
«s ess of FiG. 9 in accordance with a fourth Illustrative em- 
bodiment of the present invention. This fourth embodi- 
ment, may advantageously 'be employed when the cus- 
tomer has only a one-way fas opposed to a two-way) 
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pager, since: Hallows for the customers- confirmation tor 
be communicated indirectly through the retailer. Specif' 
fcaSy, she illustrative process ot- FiQ. 12 is idsnticai to 
thai of the aiusttatiife embodiment of FIG, 10 and FiQ. 
1 1 except in the mechanism by which the customer con- 
firmation is requested and received, 

in particular, when decision 23 determines that ii is 
okay to authorize ! he transact ion. (he illustrative system 
ot this Soufih embodiment generates a confirmation 
cods and supplies that code to the customer via his or 
her (one-way) page; (steps 4"! and 42) The supplied 
confirmation coda may. for example, be randomly gen- 
erated so as not to be predictable !ri this manner, she 
confirmation code wrii be known only to she customer 
(and not. for exempts; to- a fraudulent user of the cus- 
tomer's credit card number who is not in possession of 
the customer's pager}. The confirmation code may then 
be used to indirectly confirm the authorsaUon. For ex- 
ample, whets : the customer is njakingaface-te-face pur- 
chase in a store., the customer may provide the confir- 
mation cods supplied by the transaction processing 
■center to the retailer, who may. In turn, provide that con- 
formation code back to the transaction processing cent- 
er. This latter step may be performed, tor example, with 
use of the automated card reader which is already in 
communication with the transaction processing center 

Thus, alter the Illustrative process of FiQ. 12 has 
supplied She confirmation cods to the customer; step 43 
waits for a responsive input which includes a (return} 
confirmation code (&.g., from the automated card read- 
er) Then, the confirmation cede which was supplied for 
the given transaction is compared to the confirmation 
code that was received {decision 44) fo ensure that the 
customer is. in fact., providing a proper confirmation ot 
the attthotastfoo. It the .supplied confirmation code 
matches trie received confirmation cede, the system au- 
thorizes the transaction {steps 28 and 29). if they do not 

matron- code after a predetermined amount of time has 
elapsed, fhe ■transaction is denied (steps 24 and 29}. 

A Fifth illustrative Embodiment 

FIG. 1 3 shows allow chart of acredi! card purchase 
transaction to which a fifth illustrative embodiment ot the 
present invention may advantageously be applied. This 
fifth embodiment eliminates the need for performing 
multiple communications at the time- of purchase. That 
is. the extra am* that may otherwise be required to page 
the customer and receive a confirmation or denial of the. 
pending authorization are not needed when this fifth il- 
lustrative embodiment is employed. 

Prior to the initiation of the transaction isseit, fhe cus- 
tomer requests and receives a confirmation code for use 
in a. specifically identified subsequent transaction (steps 
51 and 52} This confirmation code; which may. for ex- 
ample, oe randomly generated, witi.be known only to the 
customer who intends to execute the specific transac- 



tion rue-., make a particular purchase), or, alternatively, 
fo an agent oi the customer (i a, the principal! lo whom 
toe customer has communicated the given confirmation 
cods. The specific transaction may, for example, be 

$ identified based on she retailer's store identification code 
(such as merchant code 203 of FIG. 2} or other identi- 
fying indicia oi the retailer. Then, when the purchase is 
initiated, the customer for the principal's informed 
agent) provides the. previously received confirmation 

if code to the retailer, who, in turn, provides the confirma- 
tion code to the transaction processing center which 
performs the automated authorization process (steps 
53-55). The automated authorization system can then 
use the received confirmation code in a manner similar 

** to that of the fourth illustrative embodiment shown in 
FIG, 12 tor purposes of confirming an authorization of 
the transaction. Note that since the two-way communi- 
cation process ot steps 51 and S2 need not occur af the 
time (or at fhe location) of the purchase but, rather, may 

*> precede the transact ion by a substantia! amount of time, 
a wide variety of communications devices (tn addition to 
one-way or two-way pagers) may advantageously be 
used in realizing the fifth Illustrative embodiment. 

FiQ. 14 shows a flow chart of an automated author- 
ration process which may be used to implement step 
55 of the process of FiQ. 1 S in accordance with fhe fifth 
illustrative embodiment of the present invention. As de- 
scribed above, upon the receipt ot a customer's request 
for a confirmation code to be used In executing a specific 

•3<? (Suture) transaction, fhe iiiustrattveauthortestion system 
generates and supplies a confirmation code to the cus- 
tomer, w addition to its being supplied to the customer, 
however, this confirmation code is associated with the 
customer identifier and, for example, the retailer store 

s& identification code, and this data is then stored in the 
transaction processing cenSer database (e.g.. validation 
database 1-08 of FIG. 1 } lor later retrieves -that is, when 
the identified transaction is actually exec uied. Thus, up- 
on a request for authorization of the given transaction, 

-w toe illustrative process of: ft©, f 4 retrieves the previous- 
ly supplied confirmation code from the database based 
on the customer identifier and She retatier store idenillh 
cation code (steps Si and 62). Then, after it is deter- 
mined that the transaction should {otherwise} be author- 

45. feed, the system verifies that the confirmation code re- 
ceived with the request for authorization matches the 
confirmation code previously supplied to the customer 
(decision S3). If they do In fact match, the authorization 
may be confirmed (steps 28 and 29). 

A Sixtn ilfustretive Embodiment 

In accordance with a sixth illustrative embodiment 
ot she present .invention, a confirmation code- may be 
«s provided to a customer without the customer making a 
specific request therefor: This embodiment may be ad' 
vantageousty applied toa credit card purchase transac- 
tion in a similar manner to the fifth illustrative embodi- 
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mem described above, in particular, the flow chart 
sitown io FIG. IS may be modified by removing step 51 
therefrom Then, instead of the customer requesting am 
receiving a confirmation cods tor use in a specifically 
identified subsequent transaction, the customer (auto- 
maticaiiy} receives a new confirmation after each trans- 
action and/or periodically fag., each morning) for use 
in his or her next transaction 8y limiting the use of the 
given confirmation code to. for example, a single trans- 
action, the advantages of the present Invention In pro- 
tectffigagams! fraudulent transactions is obtained, while 
no direct communication tram the customer to the f rans- 
acilon processing center is required. Thus, for example, 
as in the case of tne fourth and fifth illustrative embod- 
iments, one-way pagers may advantageously be used, 
Moreover, the use of a confirmation coda which does 
not match the last previously supplied confirmation code 
but. rather, matches one used in a previous transaction 
may welt be indicative of fraud. 

Although a number of specific embodiments ot this 
invention have been shown and described herein. It is 
to be understood that these embodimenis are merely 
illustrative of the many possible specific arrangements 
which can be devised In application of the prtnciptes-ot 
the invention. Nurnerousand varied other arrangements 
can be devised sn accordance with these principles toy 
those of ordinary skill in the ail without departing, tram 
the splnf: and scope o( the invention. For example, al- 
though tne embodiments described above have fo- 
cused on a credit card purchase transaction, It wit! be 
obvious So those of ordinary sk:i! in me art that the prin- 
ciples of the present invention may oa applied te a wide 
variety of transactions .including, but not .limited to, tele- 
phone caning card transactions, banking transactions 
including those using PS Ms. stock and commodity trad- 
ing transactions, and secure access transactions- such 
as computer access transactions based en computer 
passwords, in addition, the principal* oT the present in- 
vention may be applied So numerous other types of se- 
cure access transactions such as physical access (i.e., 
entry.! transactions including those used for purposes of 
inventory centra!. For example- an entry door to a secure 
room fag., a hospital's- medication room) or to a secure 
facility may be locked by an electronic tacking system 
combination keypad or card access entry) which 
s e!e -tf(y ico } ike ^ o a v6'"ia ( ac itv sunn sss the 
transaction processing center described above. Then, 
any attempt to enter the room or facility may be made 
subject to confirmation m accordance with the principals 
of the present Invention. 

In addition, although the above embodiments f o- 
cused primarily- en communication via wireless paging 
devices (e.g., one-way or two-way pagers), it mil be ob- 
vious to those skilled m the- art that many other commu- 
nications mechanisms may be used instead of, or in ad- 
dition to; wifeless, paging devices.. These mechanisms 
include, tor example, cellular telephones, conventional 
wired telephones, personal computers, .sic. 



automated method for authorizing a transaction, 
d transaction based on a customer identifier as- 
sated with a customer, the method comprising 
steps ot: 

receiving a request to authorise said transac- 
tion, said request including said customer iden- 



deten 



o said 



d request and 
based on said customer identifier, whether to 
authorize said transaction: 
if said determining step determines thai said 
transaction is to be authorized* communicating 
said determination to sad customer: 
receiving a communication from said customer 
confirming thai said customer consents so said 
transaction being authorized; and 
authorizing said transaction in response to said 
received from said customer. 



An automated method for authorizing a Iransaction. 
said transaction based on a customer identifier as- 
sociated with a customer fhe method comortsing 



receiving a request to authorize said transac- 
tion, said request including said customer iden- 

determining, sn response to said request and 
based on said customer identifier, whether to 
authorize said transact ton; 
if sa:d determining step determines that said 
transaction is to be authorized, communicating 
said determination to said customer: and deter- 
mining whether a communication indicating 
that said transaction is not to-be authorized is 
received within a given amount of time from 
said customer; and 

authorizing said transaction- il said communica- 
tion from said customer is not received wiihm 
said given amount of time, 

The method of ciaim I or S wherein said step of com- 
municating said determination to said customer 
comprises transmitting signals representative ol 
said defefminalion to a wireless- telseommuniea- 



The method of claim 3 wherein said wireless tele- 
communications receiver comprises a display and 
wherein said step of communicating said determi- 
nation to said customer 'comprises communicating 
said customer identifier to- said customer. 

The method of claim S wherein said wireless tele- 
communications receiver comprises a display and 
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wherein said step of communicating said determi- 
nation to said customs comprises communicating 
an identity of said provider to saio customer. 

The method of -claim 3 wherein said wireless teie- 
communications receiver comprises a two-way 
pager and wherein said communication from said 
customer confirming that said customs consents 
io said transaction bamg authorized is transmitted 
by said customer with use of said two-way pager. 

An automated roefhod for authorizing a . transaction, 
sasd transaction based on a customer identifier as- 
sociated with a customer the method eomerismg. 
the steps of: 

communicating to said customer a confirmation 
code for use « executing said transaction; 
receiving a request to authorize .said transac- 
tion, sad request including said customer iden- 
tifier and sa id conformation code; 
determining, tn response to said request, based 
on said customer idsntilier and based on 
whether said received confirmation code 
matches said confirmation code communicated 
to said customer, whether so authorize said 

authorizing said transaction if said determining 
step determines mat sato transaction is to be 
authorized. 

The method ot claim 7 wherein said step of commu- 
mcatmo. to said customer a confirmation code for 
use in executing said transaction is performed in re- 
sponse to receiving a communication from said cue- 
tomenndicating that said customer desires to exe- 
cute said transaction. 



to .saics customer a confirmation cods for use ;n 
completing execution ot said transaction: 
receiving a communication compnsing eaio 
connnmafion code: and 

authoring sato transaction in response to said 
received confirmation code matching said con- 
ic said customer. 



11. The method of ciatm 7 or 5 0 wherein said step ot 
communicating to said customer said contirmaiion 
code comprises encoding said comtrmation code to 
provide a secure communication thereof 

12. The method of claim 1 2. 7 or 1 0 wherein said iians- 
aeiicn comprises a sates Transaction ano wherein 
said customer identifier comprises a credit card 
number. 

1 3, The method of claim 1 . 2, ? or 1 0 wherein said trans- 
action comprises placing a telephone caii and 
wherein said customer identifier comprises a tele- 
phone cailmg card number, 

14, The method of claim 1.2.7 or \ 0 wherem said trans- 
action comprises a hanking transaction and where- 
in said customer identifier comprises a bantc card 



i. The method of ciasm t 2. 7 or 10 wherein saw cus- 
tomer identifier comprises a Personal identification 
Number: 

i. The method of claim 7 or TO wherein said step of 
communicating said confirmation code to said cus- 
tomer comprises transmitting a signs! representa- 
tive of said confirmation code tea -wireless telecom- 
m un scat ions receiver. 



S, Tne method ot claim ? turther comprising the step 
of communicating a second confirmation code to 
said customer attar authorizing said transaction, 
said second confirmation cede for use in executing 
a second transaction subsequent to said transac- 
tion and being different from said confirmation code. 

f 0. An automated method for authorizing a transaction, 
said transaction based on a customer identifier as- 
sociated with a customer, the method comprising 



receiving a request to authorise said transac- 
tion; said request including said customer iden- 

detormining. m response to said request and 
based on said customer identifier, whether to ss 
authorize said sransactiorr 
if said determining step determines that said 
tCsion is to be authorized, communicating 



'. The method ot ctam 3 or 16 wherein said wireless 
telecommunications receiver comprises a pager. 

I. An automated system for use trs authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated with a customer, the system com- 
prising: 

a receiver adapted to receive a request to au- 
thorise said transaction, said request including 
said customer identifier: 
means tor determining, in response to said re- 
quest and based on said customer identifier, 
whether to authorize said transaction; 
a transmitter adapted to communicate said de- 
termination to said customer it said means for 
determining determines that said transaction is 
?o be authorized: 

a receiver adapted to receive a cor 
from satd customer cortiirming that « 
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tomer consents so said ■■transact son bstng au- 
thorized: and 

means fee 'authorizing said transaction m re- 
sponse to sad communication received from 
said customer. 

1 9. An automated system for us© in authorizing, a trans- 
action. m6 transaction based on a customer iden- 
tifier associated wrth a customer. She system com- 
prising:, 

a receiver adapted to receive a request so au- 
thorize said transaction, said request: wcfuding 
•said customer identifier: 
means for determining, m response to said re- 
quest and based on said customer identifier, 
whether to authorize said transaction 
a transmitter adapted to communicate said de- 
termination !o said customer if said means for 
determining determines that said transaction is 
to be authored: 

a timer adapted So determine- whether a com- 
munication indicating that said transaction is 
not to be authorized is. received within a given 
amount of time from said customer: and 
means tor authorizing said transaction if said 
communication troni said customer is not re- 
ceived wnhsn said given amount of time. 

20. Art automated system tor use irs authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated wrth a customer, the system com- 
prising: 



;eiver 



to :&C 



thonze said transaction, said request including 
sate customer identifier; 
means for determining- in response to. satd re- 
quest and based on said customer identifier, 
whether fo authorize said transaction; 
a transmitter adapted to communicate to said 
customer a contirmation code for use in com- 
pleting execution of said transaction if ssso 



i dose 



? deten 



that s 



transaction is to be authorized: 
a receiver adapted to receive a communication 
comprising said confirmation code; and 
means tor authorizing said transaction « re- 
sponse fo said received contirmation cede 
matchtng said confirmation code communicat- 
ed to said customer. 



'.. A method .of processing a 
comprising the steps ot: 



i. the method 



receiving information associated with a trans- 
action initiated by an agent of a principal: 
retrieving a prosife based on said information 
associated with said transaction: 
comparing at feast a portion of saio information 
to data included in said .profile: and 
in response to said comparison, notifying said 
principal of said transaction. 

23, The method of claim 22 wherein said notifying step 
further includes tie step ot transmitting a message 
so said principal to request approval for trie trans- 



a receiver adapted to receive a communication 
from said customer indicating tfiat said custom- 
er des-os '0 s* scute s^id transaction 
a transmitter adapted to communicate to said 
customer a confirmation code tor use in execut- 
ing said transaction: 

a receiver adapted to receive a request to au- 
thorize said transaction, said request including 
said customer identifier and said confirmation 
code: 

means for determining, tn response to said re- 
quest, based on said customer identifier, and 
aassd on whether said received confirmation 
code, matches said confirmation cods comma- 
mcated to said customer, whether to authorize 
said transaction; and 

means for authorizing said transaction if said 

transaction is to be authorized. 

21. An automated system tor use in authorizing a trans- 

titser associated with a customer, the system com- 
prising: 



24. The method of claim 23 further comprising the steps 



in response so receiving said approval signal, 
authorsztng said transaction 

28. The method of claim £4 wherein the approval signal 
from the principal is transmitted from a paging de- 
vice which received fhe notification in response to 
the comparison. 

26. The method of claim 23 turther comprising the steps 



•Viftg a disapproval signal trot 



in response so receiving said disapproval $s 
rial, invalidating said transaction. 



'he method of claim 23 further comprising she step 
t invalidating said transaction when no Signal ts re- 
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cervsd from said pnncipsi in response so said re- 
quest for approval message, 

28. The method of claim 22 wherein said comparing 
step further includes the step of determining wheth- $ 
er parameters included m said second subset of in- 
formation exceed threshold values represented by 
said data snefsxted <n satd profile, 

29. A system for processing a transaction, the system- to 

■comprising: 

a database which receives information associ- 
ated wrth a transaction Initiated by an agent of 
a principal and which stores a profile defined- 
by said principal; 

a processor which at retrieves said profile from 
iki'd oatabase based cn said information asso- 
ciated with said transaction, and b) compares 
at least a port ion of said Interrelation so dafa m- *> 
eluded in satd proitie: and 
a network over which a notification signal is 
transmitted to sata principal in response to said 
comparison: 

30. The system of claim 29 wherein satd notification sig- 
nal includes a message requesting approval of the 
transaction 



tiier includes means tor determining whether pa- 
rameters included in said second subset of informa- 
tion exceed threshold values represented by said 
dafa included m said profile. 



31 . The system of claim 30 further comprising: 30 

an end-user device from which an approval sig- 
nal is transmitted by sate! principal to sard data- 
base: and 

means responsive to receiving said approval ss 
Signal at said database, for authorizing said 
transaction. 



32. The system of e!arm 31 further composing a paging 
device which a) receives the notification signal in -w 
response to the comparison, and bi transmits the 
approval signal from the principal. 

33, The system of claim 30 further comprising. 

an end-user device from which s disapproval 
signal is transmitted by said principal to said da- 
tabase: and 

means responsive Jo receiving said disapprov- 
al signal at said database, for invalidating said £G, 



34. The system of claim 30 further comprising means 
tor invalidating said transaction when no signal Is 
received from said principal in response to said re- «s 
quest for approval: message 

35. The system of claim 29 wherein said processor fur- 
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